OpenEdge Development:<br />Progress 4GL Handbook Super procedure language syntax

On the face of it, there is nothing special about a super procedure. That is, there is nothing specific in the 4GL syntax of a Progress procedure file to identify it as a super procedure. Rather, it is how the procedure is referenced by other procedures that makes it a super procedure. Having said this, there are definite guidelines to follow when you build a procedure file that you want to use as a super procedure. These guidelines are discussed in the next section. First, you’ll examine the syntax used for super procedures.

A Progress procedure file must be running as a persistent procedure before it can be made a super procedure of another procedure file. So the first step is that the code somewhere in the application must run the procedure PERSISTENT:

ADD-SUPER-PROCEDURE method

Any application procedure with access to the procedure handle of the super procedure can then add it as a super procedure to itself:

Or, in the more general case, it is possible to add a super procedure to any known procedure handle:

RUN `superproc` PERSISTENT SET `superproc-hdl`.

THIS-PROCEDURE:ADD-SUPER-PROCEDURE( `superproc-hdl` [ , `search-directive` ] ).

`proc-hdl`:ADD-SUPER-PROCEDURE( `superproc-hdl` [, `search-directive` ] ).

In addition, you can add a super procedure at the Session level, using the special SESSION handle, in which case its contents are available to every procedure running in the OpenEdge session:

SESSION:ADD-SUPER-PROCEDURE( `superproc-hdl` [, `search-directive` ] ).

The optional search-directive can be either SEARCH-SELF (the default) or SEARCH-TARGET. The significance of this option is discussed in the "Super procedure guidelines" section.

REMOVE-SUPER-PROCEDURE method

Once you add a super procedure, you can also remove it from its association with the other procedure, whether you reference it as THIS-PROCEDURE, SESSION, or some other handle:

`proc-hdl`:REMOVE-SUPER-PROCEDURE( `superproc-hdl` ).

You can execute multiple ADD-SUPER-PROCEDURE statements for any given procedure handle (including SESSION). The super procedure handles form a stack, which is searched in Last In First Out (LIFO) order when Progress encounters a RUN statement or a function reference at run time. That is, the super procedure added last is searched first to locate the entry point to run. At any time, you can retrieve the list of super procedure handles associated with a procedure using the SUPER-PROCEDURES attribute of a procedure handle:

This attribute evaluates to a character string holding the list of super procedure handles (starting with the last one added, therefore indicating the order in which they are searched) as a comma-separated character string.

Changing the order of super procedures

`proc-hdl`:SUPER-PROCEDURES

If the ADD-SUPER-PROCEDURE method is executed for a procedure handle already in the stack, Progress moves it to the head of the list (that is, to the position of being searched first). If the procedure was already first in the stack, no change occurs and no error results. For example, this sequence of statements results in the SUPER-PROCEDURES attribute returning the handle of Super2 followed by the handle of Super1:


hProc:ADD-SUPER-PROCEDURE(hSuper1). hProc:ADD-SUPER-PROCEDURE(hSuper2). hProc:ADD-SUPER-PROCEDURE(hSuper2).

And this sequence results in the SUPER-PROCEDURES attribute returning the handle of Super1 followed by the handle of Super2:


hProc:ADD-SUPER-PROCEDURE(hSuper1). hProc:ADD-SUPER-PROCEDURE(hSuper2). hProc:ADD-SUPER-PROCEDURE(hSuper1).

You can also rearrange the order of super procedure handles on the stack by invoking a sequence of REMOVE-SUPER-PROCEDURE and ADD-SUPER-PROCEDURE methods. Each REMOVE-SUPER-PROCEDURE method removes that handle from the list, wherever it is. And each ADD-SUPER-PROCEDURE method adds the named handle to the head of the list. A handle is never added to the list a second time.

Invoking behavior in super procedures

The Progress interpreter effectively adds the contents of the super procedures to the name space of the procedure that added it. Therefore, you can invoke the internal procedures and functions defined in a super procedure simply by referencing them as if they were actually implemented in the other procedure. The interpreter locates the routine and executes it.

In addition, because Progress compiles each procedure separately, each has its own compile-time name space, so you can define the same routine in one or more super procedures and also in the other procedures to which they are added. This functionality lets you build hierarchies of behavior for a single entry point name, effectively creating a set of classes that implement different parts of an application’s standard behavior. A local version of an internal procedure can invoke the same routine in its (first) super procedure using this statement:

RUN SUPER [ ( `parameters` ) ].

If the internal procedure takes any parameters (INPUT, OUTPUT, or INPUT-OUTPUT) it must pass the same parameter types to its super procedure in the RUN SUPER statement. Note that these parameter values do not have to be the same. You might want to change the parameter values before invoking the behavior in the next version of the internal procedure, depending on your application logic.

Likewise, a user-defined function can invoke behavior in a super procedure using the expression:

SUPER ( [ `parameters` ] ).

This invokes the same function name in the super procedure and passes any parameters to it just as an internal procedure RUN SUPER statement does. The SUPER() expression returns from the super procedure whatever value and data type the function itself returns.

Each super procedure in turn can invoke the next implementation of that same routine up the stack by using the same SUPER syntax.

You must place a RUN SUPER statement inside an implementation of the invoked internal procedure and you must use exactly the same calling sequence. You can place any other 4GL definitions or executable code before or after the SUPER reference. This placement lets you invoke the inherited behavior before, after, or somewhere in the middle of the local specialization of the routine.